寫 Web 程式，只達到需求是 59 分，有注意安全才到 80 分，再考慮效能最佳化是 90 分，最後那 10 分，是界面與操作流程的完善。
Web programmer 們是依靠程式語言本身具備的安全？還是自己仔細判斷每個環節可能會發生的漏洞？
如果不想要自己寫的 Web 站台一上線就變成駭客的禁臠，該重新審視看看你的程式還可以加強什麼，比如瞭解 magic_quotes 對 php 程式的影響。
PHP programmer 若是從 PHP v4 或甚至更早的版本開始寫，一定對 magic_quotes_gpc 這個設定不會陌生。早期的 PHP 為了防止 user 端送到 server 端的資料，會被惡意內容攻擊，有 SQL injection 的疑慮，因此很體貼地設計一個這樣的開關。當 magic_quotes_gpc=on 時，$_GET、$_POST、$_COOKIE 等等從 user 端來的資料，如果含有單引號、雙引號、反斜線等內容，會自動被加一條反斜線在前面，把該字元跳脫掉，也就是做 addslashes() 的處理，以免生手 programmer 直接就把資料串在 SQL 指令上，導致系統沒兩天就被駭客爆台。在我自己剛使用 PHP 的前一兩年，老實說這個設定可能在暗中已經默默幫我擋掉不少 SQL injection 攻擊了。

但是，正如 C 語言的問世宗旨，優秀的語言不該替 programmer 顧慮太多旁支末節。當防範 SQL injection 已經成為 Web Programming 的基礎 ABC 之後，多了這個手續反而讓 PHP 的程式有移植困難、還得去偵測執行環境的 magic_quotes_gpc 是 on 還是 off，再判斷需不需要 addslashes()，根本是浪費時間的步驟。

於是，PHP 從預設 magic_quotes_gpc = on，變成預設 magic_quotes_gpc = off，再到 PHP 5.3 版之後，宣告拿掉了這個功能。

PHP 此舉是要 programmer 自己處理 user variables。事實上也只有 programmer 自己才知道該怎麼處理。因為資料不見得都是要送往資料庫，自然不必通通都來 addslashes() 一下，徒讓某些資料前面硬是多了個怪怪的反斜線。

沒有了 magic_quotes_gpc，唯一比較困擾的是舊年代的 php 系統。它們已經依賴 magic_quotes_gpc 幫它們做第一道 user input 的防線，一旦 PHP 升級到 5.3 之後，再也沒有這一道防護，資料中只要含有引號，勢必馬上出錯。如果要修正，又得在所有接收 user variables 的地方，把這些變數都給 addslashes() 一下，並且再全面進行測試。這工程可浩大了。有沒有像 magic_quotes_gpc 那樣，一個設定就可以自動為 user variables 做 addslashes() 處理的呢？當然，神關了你一扇窗，就會為你開一扇門。Filter 這個從 PECL 變成PHP預設內建的模組，就可以用來彌補沒有 magic_quotes_gpc 的環境，而且功能強更多。

在 PHP 這種弱型別的 script 語言中，沒有 compiler、executer 為你做資料型別的 check，很多 Bug 或安全漏洞就補不勝補。Filter 能為你做更多的 user variables 的過濾與檢查。而不單單只是 magic_quotes_gpc 做的 addslashes() 這麼陽春。如果想瞭解更多，可以詳加研讀官方站的 Filter 說明。本文先簡單地示範一下，如果你使用的 PHP 是已經取消 magic_quotes_gpc 的 5.3 版以上，卻有舊的 PHP 系統是吃 magic_quotes_gpc=on 的設定，那麼只要在 php.ini 上的 filter.default = 這個設定上，改為 filter.default = magic_quotes ，那麼效果就跟 magic_quotes_gpc=on 完全一模一樣了。

如果是有的站台需要，有的站台不需要，那麼就不能改在 php.ini 上，因為這是全域的設定。可以在該站台的 apache <VirtualHost> 設定內，加上 php_value filter.default magic_quotes 設定值，就會只作用在這個站台而已。依此類推，你也可以用 <Directory> 或 <Files> 來包住 php_value filter.default magic_quotes，只讓特定目錄裡的 php 或特定 php 程式會有 magic_quotes 的效果。